home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Very Best of Atari Inside
/
The Very Best of Atari Inside 1.iso
/
mint
/
mtt10
/
minttips.doc
< prev
next >
Wrap
Text File
|
1992-05-22
|
7KB
|
133 lines
ACHTUNG: Die Betriebssystem-Funktion, die zur Auswahl des seriellen Ports auf
TT/Mega-STE notwendig ist (Bconmap), funktioniert unter MiNT erst ab Version
0.95, Patchlevel 2 richtig. Wer eine ältere Version verwendet, sollte MTT auf
Port 1 konfigurieren (siehe auch MTT.DOC, Abschnitt "Parameterdatei").
Tips für den Betrieb unter MiNT
-------------------------------
Folgende Vorgehensweisen haben sich für den "Nebenher"-Betrieb unter MiNT be-
währt:
- Man startet mithilfe des zu MiNT gehörigen BGACC-Accessorys eine Shell (wie
z.B. die mintshel). Aus dieser heraus kann man bequem MTT aufrufen.
ACHTUNG: Wenn MTT nicht im "Silent"-Modus läuft, sollte man darauf achten,
daß während der Verbindung mit der MAUS nicht für lange Zeit eine Dialogbox
oder ein Alert von einem anderen Programm auf dem Bildschirm steht oder ein
Menü heruntergeklappt bleibt. Der Grund dafür ist, daß währenddessen der
Bildschirm für Ausgaben gesperrt bleibt, und somit keine Ausgaben im BGACC-
Fenster erfolgen können. Dadurch wird MTT nach einiger Zeit blockiert, wenn
es Ausgaben machen will, was zu Protokollstörungen führen kann.
Wenn man MTT trotzdem unter o.g. Bedingungen betreiben will, sollte man es
entweder im "Silent"-Modus starten (wobei es keine Ausgaben macht), oder das
BGACC-Fenster währenddessen schließen (der Prozeß darin läuft trotzdem weiter).
Dieses Problem tritt natürlich nur während des Transfers auf, bei der Anwahl
(die ja meist das nervigste ist :-), treten keinerlei Probleme auf; man kann
nebenher praktisch machen, was man will.
- Starten unter einem Window-Manager (wie MW). MTT harmoniert auch gut mit den
bisherigen Beta-Versionen von MultiTOS. Bzgl. Menüs und Dialogboxen gelten
dieselben Bedingungen wie bei BGACC (es bleibt zu hoffen, daß die Program-
mierer in Zukunft langandauernde Dialoge in Fenster verlegen, so daß sie den
Bildschirm nicht mehr für andere Programme blockieren).
- Anschließen eines Terminals an den ST und Starten von MTT im Hintergrund mit
Umlenkung auf dieses Terminal (von einer Shell aus). Als Terminal kann z.B.
ein über Midi angeschlossender Zweit-ST dienen (Umlenkung auf u:\dev\midi).
Technische Hinweise zum Betrieb unter MiNT
------------------------------------------
Wenn MTT gestartet wird, schaut es zunächst nach, ob bereits ein anderer Prozeß
mit dem Namen "MTT" läuft. Falls dies der Fall ist, weigert es sich zu starten.
Der Grund dafür ist, daß es mir mehrfach passiert ist, daß ich aus Versehen ein
weiteres MTT gestartet habe, während bereits ein anderes lief, und dadurch des-
sen Verbindung bei der Modem-Initialisierung des neuen MTT unterbrochen wurde.
Daher ist es vorerst nicht möglich, mehrere MTTs gleichzeitig zu starten. Dies
wird geändert, sobald MiNT Locking-Möglichkeiten für die seriellen Ports an-
bietet.
Beim Betrieb unter MiNT werden folgende Signale abgefangen: SIGINT, SIGQUIT,
SIGTERM und SIGHUP. Die ersten drei führen dazu, daß MTT das Logfile speichert,
ggf. das Modem auflegt und dann terminiert (in der Tat macht auch mtt_kill
nichts anderes, als MTT ein SIGTERM-Signal zu schicken). Bei SIGHUP wird das
nur dann so gehandhabt, wenn es nicht im Silent-Modus gestartet wurde, anson-
sten wird SIGHUP ignoriert. Daher ist es z.B. möglich, es unter einem Window-
Manager im 'unsichtbaren' Hintergrundbetrieb zu starten und dann das Fenster
zu schließen, ohne daß MTT terminiert (vorausgesetzt, der Window-Manager hand-
habt SIGHUP richtig).
In MTT sind einige Maßnahmen getroffen, um die vorhandene Rechenzeit möglichst
optimal zu nutzen. So wird der MTT-Prozeß z.B. 'schlafen gelegt', wenn Warte-
pausen eingelegt werden, sowie teilweise während der Anwahl. Dadurch verbraucht
es hierbei sogut wie keine Rechenzeit. Während der Verbindung ist MTT in der
Lage, den Rechenzeitverbrauch in gewissen Grenzen dem Bedarf anzupassen. So
wird, wenn MTT bei der Verarbeitung der Zeichen gut hinterherkommt, freiwillig
Rechenzeit an die anderen Prozesse abgetreten, sowie ggf. die Prozeß-Priorität
heruntergesetzt. Andererseits wird, wenn es nicht so gut hinterherkommt, die
Priorität heraufgesetzt. Dabei werden die Stufen -16 (niedrige Prio.), 0
(normal) und +16 (hoch) benutzt.
Das mtt_stat-Programm kommuniziert mit MTT über eine Message-Pipe mit dem Namen
"u:\pipe\MTT_STAT.MSG".
Performance-Probleme
--------------------
Benutzer von High-Speed-Modems sollten sich darüber im Klaren sein, daß die
Rechenleistung des STs bzgl. der Geschwindigkeit Grenzen setzt. Beim Betrieb
ohne MiNT kommt MTT auch bei effektiven 19200 Bd noch problemlos mit. MiNT
verschärft die Situation aus zwei Gründen:
(1) Der Overhead von Betriebssystemaufrufen ist hier erheblich höher (und MTT
muß für _jedes_ einzelne Zeichen mindestens einen Aufruf machen).
(2) Wenn noch weitere Prozesse nebenher laufen, bekommt MTT naturgemäß nicht
die volle Rechenzeit.
Unter MiNT ist ein 8-MHz-ST bei 9600 Bd schon ziemlich damit ausgelastet, die
Zeichen von der Schnittstelle abzuholen (das ist wohlgemerkt eine effektive
Baudrate, also was das Modem auf der Telefonseite tatsächlich überträgt; wenn
beispielsweise ein 2400/MNP5-Modem mit 9600 Bd mit dem Rechner kommuniziert,
gibt es keine Probleme). Mit einem Speeder oder auf einem TT erreicht man
natürlich entsprechend mehr.
Zu Testzwecken habe ich einen 8-MHz-ST per Nullmodem-Kabel mit einem ST mit
16-MHz-Hyper-Cache verbunden und bei verschiedenen Baudraten längere Files
mit Zmodem zwischen den beiden übertragen. Als Richtwert gebe ich im folgenden
an, was der 8-MHz-ST beim Zmodem-Empfang zustandebrachte:
- Unter TOS ohne MiNT gab es auch bei 19200 Baud keinerlei Probleme.
- Unter MiNT kam der 8-MHz-ST beim Zmodem-Empfang im Streaming-Modus bis
9600 Baud problemlos mit, wenn keine anderen Prozesse nebenher liefen
- Wenn es in einem MW2-Fenster lief und nebenher noch ein langes C-Programm
kompiliert wurde, klappte der Empfang bis etwa 4800 Bd im Streaming-Modus
einwandfrei, bei 9600 Bd gab es einige Retries und der Durchsatz sank
- Bei ausgeschaltetem Streaming verlief die Übertragung in jedem Fall fehler-
frei, jedoch mit begrenztem Durchsatz (schwankend je nach Auslastung,
etwa zwischen 500 und 800 CPS)
Wenn es Probleme beim Transfer gibt, ist also die erste Maßnahme, das
Streaming beim Empfang auszuschalten (Parameter `RZ-No-Streaming'). Damit ist
die Übertragung weitgehend sicher (wenn auch mit einem etwas kleineren Durch-
satz). Notfalls läßt man den Rechner zwischen Zustandekommen und Ende der Ver-
bindung ganz in Ruhe. Die Anwahl dagegen ist völlig unkritisch.
Beim Hintergrundbetrieb sollte man allgemein während der Verbindung darauf
achten, daß der Rechner im Vordergrund nicht zu sehr belastet wird und MiNT
dem MTT-Prozeß ausreichend Rechenzeit geben kann. Ein paar Tips, was man bei
Hintergrund-Betrieb generell besser unterlassen sollte:
- Umfangreiche Disketten-Operationen wie z.B. Kopieren von langen Dateien oder
Formatieren, denn dabei läuft der Rechner längere Zeit im BIOS und MiNT kann
nur selten Taskwechsel durchführen.
- Irgendwelche Programme laufen lassen, die auf den gleichen Port zugreifen
über den MTT läuft (Chaos garantiert)
- Den Rechner zum Absturz bringen oder abschalten, während MTT im Hinter-
grund läuft :-)
Stephan Baucke, April 1992